Critical bug: This updates the wrong database field. The implementation updates organizations.plan, but the actual plan assignment is managed through the org_quotas table's plan_id field. This is evident from:

1. EnsurePlanAssigned function which updates OrgQuota.PlanID (apps/shared/pkg/services/organizations/plan_assignment.go:68-85)
2. organizationToProto function which loads plan info from org_quotas table (line 1504-1543 in this file)

The correct approach is to update the org_quotas.plan_id field, similar to how EnsurePlanAssigned does it. Consider:

var quota database.OrgQuota
err := database.DB.First(&quota, "organization_id = ?", orgID).Error
if err != nil {
    if errors.Is(err, gorm.ErrRecordNotFound) {
        // Create new quota if it doesn't exist
        quota = database.OrgQuota{OrganizationID: orgID, PlanID: planID}
        err = database.DB.Create(&quota).Error
    }
    // handle error
} else {
    quota.PlanID = planID
    err = database.DB.Save(&quota).Error
}

Incorrect permission check: The function uses auth.IsSuperadmin(ctx, user) but other similar admin functions in this service use auth.HasSuperadminPermission(ctx, user, "permission_name") for fine-grained permission checks. For example, AdminAddCredits (line 1771) and AdminRemoveCredits (line 1842) use auth.HasSuperadminPermission.

For consistency and better access control, consider using a specific permission like:

if !auth.HasSuperadminPermission(ctx, user, "organization.admin.set_plan") {
    return nil, connect.NewError(connect.CodePermissionDenied, fmt.Errorf("superadmin access required"))
}

This configuration change (setting compatibilityVersion: 4) appears unrelated to the stated purpose of this PR. Changing the Nuxt compatibility version is a significant framework upgrade that could have wide-ranging effects on the application behavior and should be:

1. Thoroughly tested across the entire application
2. Documented in the PR description
3. Ideally handled in a separate PR focused on the framework upgrade

If this change is intentional and necessary for the set-plan feature, please explain why in the PR description. Otherwise, it should be reverted.

The entire CLAUDE.md file addition appears unrelated to this PR's stated purpose of adding superadmin set-plan functionality. This is a comprehensive documentation file about the project structure and development practices.

While this documentation may be valuable, it should be added in a separate PR dedicated to documentation improvements, not bundled with a feature implementation PR. This makes the PR harder to review and mixes unrelated concerns.

Potential ambiguity in zero value display: The code displays 0 values as '∞' (infinity) for CPU cores, deployments, and VPS instances (e.g., line 162: selectedPlanInfo.cpuCores || '∞'). However, in the database schema, 0 is used to represent "unlimited" for some fields (e.g., MaxVpsInstances in OrganizationPlan model), but for other fields like CPUCores, 0 likely means "none" rather than "unlimited".

This could confuse users if a plan actually has 0 CPU cores (which would be invalid) vs unlimited. Consider:

1. Using a more explicit check like selectedPlanInfo.cpuCores === 0 || selectedPlanInfo.cpuCores === null ? '∞' : selectedPlanInfo.cpuCores
2. Or displaying 0 as 0 and using -1 or null to represent unlimited
3. Adding validation to ensure critical resources like CPU can't be 0

Missing input validation: The plan_id should be validated to ensure it corresponds to an actual plan in the organization_plans table before attempting the update. Without this check, the system could be configured with an invalid plan ID that will cause downstream errors when trying to load plan information.

Add validation similar to what's in EnsurePlanAssigned:

var plan database.OrganizationPlan
if err := database.DB.First(&plan, "id = ?", planID).Error; err != nil {
    if errors.Is(err, gorm.ErrRecordNotFound) {
        return nil, connect.NewError(connect.CodeInvalidArgument, fmt.Errorf("plan not found: %s", planID))
    }
    return nil, connect.NewError(connect.CodeInternal, fmt.Errorf("failed to validate plan: %w", err))
}

Missing error check on database result: The code doesn't verify that the UPDATE actually affected any rows. If the organization_id doesn't exist, the Exec will succeed silently without updating anything. This could lead to confusing behavior where the API returns success but no change occurred.

Add a check like:

if result.RowsAffected == 0 {
    return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("organization not found"))
}

This configuration change appears unrelated to the stated purpose of this PR (adding superadmin set-plan functionality). The apiHostInternal URL is changed from http://localhost:80 to http://api.localhost, which is a significant infrastructure change that could affect local development routing.

If this change is intentional and necessary, it should be explained in the PR description or split into a separate PR. Otherwise, it should be reverted to keep this PR focused on the set-plan feature.

This comment update appears unrelated to the stated purpose of this PR (adding superadmin set-plan functionality). The change clarifies the behavior of HEALTHCHECK_TYPE_UNSPECIFIED, but belongs in a separate documentation or deployment service PR.

Method placement inconsistency: The AdminSetPlan RPC is placed at the beginning of the service definition (line 13), while other admin methods like AdminAddCredits and AdminRemoveCredits are grouped together later (around lines 61-64 in the original file). For consistency and better organization, consider moving AdminSetPlan to be grouped with the other admin methods.